Most plant IT teams have received at least one SBOM by now, usually as a PDF or spreadsheet attached to a change notice, and most of those SBOMs have gone straight into a project folder never to be opened again. That’s not a criticism of the people receiving them — it’s a workflow gap. CISA has spent the last several years building out expectations for software bills of materials in critical infrastructure, and NIST’s guidance on SBOM formats and minimum elements has matured alongside it. Secure-by-design language is now showing up in RFPs for PLCs, HMIs, and MES platforms, sometimes because a federal contracting requirement flows downstream, sometimes because a corporate security team read the CISA guidance and decided to get ahead of it. Either way, the document is arriving. The question practitioners haven’t answered yet is what to do with it once it lands.
My position: an SBOM that isn’t tied to your live asset inventory and your patch calendar is a compliance artifact, not a security control. Treating it that way — filing it, checking a procurement box, moving on — wastes the one piece of leverage you now have over vendors who have historically told you nothing about what’s inside their firmware.
What an SBOM actually gives you
A software bill of materials, in the CycloneDX or SPDX formats that dominate this space, is a structured list of the components — libraries, frameworks, open-source packages, sometimes down to specific versions — that make up a piece of software or firmware. For a PLC’s firmware image or an MES application server, that might mean identifying an embedded TLS library, a JSON parser, a Linux kernel version, or a logging framework, each with a version number you can check against vulnerability databases.
That’s the entire value proposition: it converts “is this PLC vulnerable to CVE-2024-XXXXX” from a question you’d have to ask the vendor and wait weeks for, into a question you can answer yourself in an afternoon, provided you’ve built the machinery to answer it.
The gap between having an SBOM and using one
Here’s where most OT security programs stall. An SBOM by itself doesn’t tell you if a vulnerable component is exploitable in your deployment, whether it’s reachable from your network segmentation, or whether patching it will break a certified control loop. It’s raw material. You still have to do the work of correlating it against:
- Your actual asset inventory — which controllers, HMIs, and MES servers are running which firmware or software version, right now, on the plant floor
- The National Vulnerability Database or CISA’s Known Exploited Vulnerabilities catalog, to see which components have disclosed CVEs and which of those are actually being exploited in the wild
- Your network architecture, per IEC 62443 zone and conduit models, to judge whether a vulnerable component is actually reachable by an attacker or sitting behind enough segmentation that it’s a lower-priority fix
- Your production calendar, because a patch that’s technically urgent on a CVSS score basis may still have to wait for a scheduled downtime window on a line running three shifts
None of this happens automatically. It requires someone — usually a controls engineer or plant IT security lead, sometimes an OT-aware vulnerability management tool — to actually run the matching exercise.
Building the workflow, not just collecting the document
The practical version of this looks less like a security initiative and more like a recurring maintenance task. When a vendor delivers an SBOM, whether for a new PLC firmware release, an HMI runtime update, or an MES version upgrade, the receiving team should:
- Ingest the SBOM into a tool or spreadsheet that can diff component versions against known-vulnerable lists — several commercial and open-source SBOM analysis tools now do this automatically, cross-referencing against NVD feeds
- Tag each flagged component with the specific assets running it, pulled from your CMMS or asset management system, not a guess
- Score priority using both CVSS and exploitability context — a critical CVE in a component that’s air-gapped and unreachable ranks below a medium-severity flaw in something facing the plant network
- Slot the fix into the next available maintenance window rather than treating every finding as an emergency patch, because in OT, “patch now” often isn’t an option and shouldn’t be the default recommendation anyway
This is genuinely more work than most plants are staffed for today. That’s the honest tradeoff. But it’s a fixed, bounded amount of work per SBOM delivery — not an open-ended security program — and it’s work that pays for itself the first time you can tell a plant manager, with actual evidence, that a newly disclosed CVE doesn’t affect your environment instead of shutting a line down out of caution.
What to put in the next RFP
If you’re revising procurement language for PLCs, HMIs, or MES platforms, the CISA and NIST direction gives you cover to ask for specifics that vendors used to wave off. Worth writing into contracts and RFPs directly, rather than leaving as a vague “vendor shall provide security documentation” clause:
- SBOM delivery in a machine-readable format (CycloneDX or SPDX, not a PDF) at time of purchase and with every subsequent firmware or software update
- A defined notification window for newly disclosed vulnerabilities affecting delivered components — days, not “when convenient”
- Clarity on what the vendor will and won’t patch for end-of-life or long-deployed hardware, since a lot of PLCs stay in service well past the software support lifecycle of their embedded components
- A named point of contact or process for vulnerability disclosure questions, so you’re not routing an urgent question through a generic sales channel
Vendors serious about secure-by-design practices — a term CISA has pushed hard since 2023 — generally aren’t put off by this language; some already produce SBOMs for other regulated customers and can hand you the same artifact with minimal friction. Vendors who resist basic SBOM delivery terms are telling you something about their internal software supply chain visibility, and that’s useful information to have before you sign, not after.
The real shift here
The mandatory-SBOM push isn’t really about the document. It’s about forcing a level of transparency into ICS and MES supply chains that the industry has gotten away without for a long time, largely because PLCs and HMIs were treated as sealed appliances rather than software products with dependencies like anything else. That era is ending, slowly, through procurement pressure more than through any single regulation. Plants that build the internal muscle to consume SBOMs operationally — matching components to assets, prioritizing against real production constraints, and holding vendors to delivery terms in the contract — will be the ones actually getting security value out of this shift. Everyone else will keep collecting PDFs.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
